Building a Shared Library Using Versioning

When you first build your shared library, give it an initial version, for example, sgi1.0. Add the option -set_version sgi1.0 to the command to build your shared library (cc -shared, ld -shared).

Whenever you make a compatible change to the shared object, create another version by changing the minor version number (for example, sgi1.1) and add it to the end of the version_string. The command to set the version of the shared library now looks like -set_version "sgi1.0:sgi1.1".

When you make an incompatible change to the shared object:

1. Change the filename of the old shared object by adding a dot followed by the major number of one of the versions to the filename of the shared object. Do not change the soname of the shared object or its contents. Simply rename the file.

2. Update the major version number and set the version_string of the shared object (when you create it) to this new version; for example, -set_version sgi2.0.

• When an executable is linked against a shared object, the last version in the shared object's version_string is recorded in the executable as part of the liblist. You can examine this using elfdump -Dl.

• When you run an executable, rld looks for the proper filename in its usual search routine.

• If a file is found with the correct name, the version specified in the executable for this shared object is compared to each of the versions in the version_string in the shared object. If one of the versions in the version_string matches the executable's version exactly (ignoring comments), then that library is used.

• If no proper match is found, a new filename for the shared object is built by combining the soname specified in the executable for this shared object and the major number found in the version specified in the executable for this shared object (soname.major). Remember that you did not change the soname of the object, only the filename. The new file is searched for using rld's usual search procedure.